-
-
Notifications
You must be signed in to change notification settings - Fork 90
FIx coverage for generate scopes #1184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1c73d35
to
760d0f6
Compare
Hi, Instead, I added @nickg do you have any way on how to debug the failing test on MAC OS ? I don't have MACOS |
67ad74b
to
5de1e23
Compare
Hi, |
0fcba62
to
f018509
Compare
Hi @nickg , |
I don't think this is really a problem: if the user wants the path names to be distinct he can use the alternative labels which are provided by the language for exactly this purpose. I don't like using the locations for anything that's not just information displayed to the user.
Yeah I guess it's a bug introduced when I added the accelerated versions. Fixed it in 5f47fdb. |
OK. I will remove the |
f018509
to
d61cd37
Compare
d61cd37
to
c336ac9
Compare
Hi,
this is a proposal for fixing the generate scopes not being emitted as coverage "instance" scopes.
It works well for
for generate
becauseT_BLOCK
name for the generate has iterator variable suffix.In case of
if generate
orcase generate
, only a single block is elaborated at single simulation.A branch / choice inherits name of the parent generate statement, unless overridden by a branch / choice
specific
alternative_label
. If user omitsalternative_label
, than different HDL items may end up withthe same code coverage item name (in a different elaborations / simulations). When merging the code
coverage data from such simulations, such data aliases.
Consider e.g. following example:
Where
G_PAR
is a top level generic of the entity instantiating thiscase generate
statement.Upon elaborations with
G_PAR
ranging from 0 to 3, each of the signal assign statements fromc
up tof
will have following coverage item name:since the implicit statement / process / branch / expression labelling always counts the equally
within distinct coverage scopes. Merging of code coverage from such simulations gives confusing
results and false positives.
An obvious approach how to fix this, would be appending the branch / choice index to a name
of implicit block that is created for such choice / branch. Such "conflict avoidance" would work
very similarly to implicit labelling of statements / processes / expressions for code coverage.
Do you think it is better to append such "implicit counter" to the name of the created code coverage
scope only, or to the name of the implicit block ? Or would you choose another approach ?